RE: Administrivia: List Announcement

From: Oliver Lavery (oliver.lavery_at_sympatico.ca)
Date: 08/09/02

  • Next message: Gustavo Scotti: "RE: Administrivia: List Announcement"
    To: "'Gustavo Scotti'" <gscotti@axur.com.br>
    Date: Fri, 9 Aug 2002 04:57:59 -0400
    
    

            Agreed up to here. Freeing a buffer that is not NULL terminated is
    fine, you're right. The first example is 'just a bug'. The second one is a
    security risk and a bug.

    > I don't think this is a shabby way to copy a string. An
    > hipotetical char = 16 bits, not even your malloc is misused,
    > like your for is incoherent. Yes, the correct loop would be i
    > < SIZE. Ops can be reduced if your compiler could optmize it.
    > If you force an arch based optmization (like the one you
    > proposed), it is totally arch dependent.
    >

            It's not as arch specific as you think. Provided you are using 8 bit
    character strings, which is sort of implied as I read it, then it is pretty
    bad. Take a look at the implementation of strcpy in a good CRT, it should be
    much smarter than this loop. Yes good compilers can optimize this, but you
    can express that optimization in vanilla C, which prevents the compiler from
    having to; premature optimization may be the root of all evil, but immature
    optimization follows closely on it's heels. The for loop string copy is a
    good example of trying to be smarter than you really are; calling strncpy is
    often faster.

            Copying a string 32bits at a time rather than 8 is just better. Yes
    if we switch to wide-char strings on Windows, for example, it will break,
    but so will code that uses strncpy. But we digress into nit-picking and the
    sort of subjective coding debate that never ends...

    Cheers,
    ~ol


  • Next message: Gustavo Scotti: "RE: Administrivia: List Announcement"

    Relevant Pages

    • Re: Noob Guestion About Make.conf
      ... Note that optimization settings other than -O and -O2 ... submitting bug reports without patches to the developers. ... FreeBSD world needs all the compiler hackers it can get:) ...
      (comp.unix.bsd.freebsd.misc)
    • Re: Function prefix comments in C files
      ... now that reminds me of a bug I spent an unreasonable time searching ... It turned out that when the compiler had its ... default optimization level on the access to the pointer was ... With optimization turned off access was no longer atomic and it ...
      (comp.arch.embedded)
    • Re: buggy optimization levels...
      ... >> particularly if the failures aren't concise and completely reproducable, ... >> the optimization that caused the observed failure is thus also hard. ... It may be a bug in gcc, but it may also be a bug in the code ... compiler optimizations likes -fgcse are not allowed to change the meaning ...
      (freebsd-questions)
    • Re: buggy optimization levels...
      ... It may be a bug in gcc, but it may also be a bug in the code ... with -O3 or when compiled with -O2 or lower optimization follows: ... When compiled with -O2 or lower the compiler is not able to determine ...
      (freebsd-questions)
    • Re: How much efficient is Java 6 to Java 1.3?
      ... the same optimizations applied as code in Java 6. ... Yes, optimization is done at runtime, but newer compiler may generate ... For example addition of strings in 1.3 ...
      (comp.lang.java.programmer)

    Loading