Advent4 patch, second try

[Pierre Riteau]

On 9/26/07, Luis Javier Merino <ljmerino at gmail.com> wrote:
> On 9/26/07, Stefan Sperling <stsp at stsp.name> wrote:
> > And it's lazy and stupid not to test the condition explicitely.
> > Something like:
> >
> >         if ((sptr = strchr(username, '\n')) != NULL)
> >
> > is easier to understand for humans and the same to the compiler.
>
> Sure. Use NULL for comparing against pointers. For integers the UNIX
> convention is returning -1 on errors, so compare using "< 0".
>
> >
> > Or simply avoid assigning inside a conditional statement altogether.
> > Even if just not to confuse newbies reading the code.
>
> Fine, it can also make code more readable by virtue of having shorter
> code lines.
>
> >
> > If you need to know tons of crazy idioms to read code,
> > it's not well written. This attiude leads to brain-damaged
> > stuff like using
>
> But knowing some idioms is valuable to be able to read other people's
> sources, assignment inside an if condition is one of those idioms.
>
> >
> >         *((char *) mempcpy (dst, src, n)) = '\0';
> >
> > to copy a string.
> >
> > (see http://ecos.sourceware.org/ml/libc-alpha/2000-08/msg00061.html)
>
> :)  You're criticizing Ulrich Drepper.
>
> Jonathan, if you're learning C, that's a good thread to read. Bottom
> line: str* functions are a bad idea, programs wich do heavy string
> processing should use dynamically allocated strings (or a language
> other than C), as an example qmail and postfix implement their own
> string handling functions.
>
Actually strl* functions are an answer to these problems without
having to use dynamically allocated buffers, but Ulrich Drepper is
responsible for them not being included in glibc while it is available
on all BSDs, Solaris and Mac OS X.

> >
> > > Aside from that, I wouldn't really lose time fixing warnings on  code
> > > written for pre-ANSI compilers.
> >
> > True, but at the same time these warnings are quite annoying.
> >
>
> I just think it's more useful to learn to remove warnings from more
> modern programs, which are more likely to reflect code defects and not
> code archaicisms.
> --
> dslinux-devel mailing list
> dslinux-devel at dslinux.in-berlin.de
> http://mailman.dslinux.in-berlin.de/mailman/listinfo/dslinux-devel
>