Re: Compile error in current CVS, src/server.c:5500

[Mark D. Baushke]

Derek Robert Price <derek@ximbiot.com> writes:

> Mark D. Baushke wrote:
> 
> >Hi Pavel,
> >
> >Actually, your patch is not yet consistent with the need to deal with
> >pre-ANSI compilers (altough much of those requirements appear to have
> >been dropped recently). In any case, the error needs to be structured a
> >bit differently with the 'error' keyword on the second line and return
> >value provided as well.
> >
> 
> Yeah, and I was in the not particularly hurried process of removing
> more of them.  As I understand from the discussion in the GNULIB
> forum, HP-UX is the last system anyone there will mention to ship with
> a K&R compiler and even GCC isn't supporting K&R compilers anymore.
> If an HP-UX admin doesn't buy the commercial HP-UX compiler they need
> to bootstrap even gcc with an old version of GCC.

Yup, HP-UX is the last bastion of K&R C in a currently supported
release. Of course, both SunOS 4.x and older IRIX boxes have the same
problem, but at least they moved forward to ANSI C on their currently
supported releases.

> We also use GNULIB modules which no longer support K&R (none of GNULIB
> does) and if we really need to we (or an end user) could resort to
> automake's automatic support of the ansi2knr script.

I'd rather not need to do that, but I can understand the reasons why it
might have to happen.

> Do you know when split strings began being supported?  C89?  

Yup.

There was much contention and debate during drafts of the ANSI C
standard, but I am fairly sure that ANSI/ISO 9899-1990 (aka C89) is the
first one to force the behavior (section 6.1.4 "String Literals").

Where the grammer is

  Syntax:
    string-literal
        "s-char-sequence[opt]"
        L"S-char-sequence[opt]"
    s-char-sequence:
        s-char
        s-char-sequence s-char
    s-char
        any member of the source character set except
            the doulbe quote ("), backslash (\), or new-line character
        escape-sequence

So you will note that the new-line character has never actually been
a formal part of the string-literal without being escaped. It is only
in recent compilers that this is being enforced.

In ISO/IEC-9899-1999 (aka C99), the same syntax is provided (but it is
now in section 6.4.5 String Literals). The only real change is that the
text of the description and semantics has been expanded for
clarification and the single-quote clarified as having two
representations (either "'" or "\'").

> I had noticed that I was getting deprecation warnings for multi-line
> strings from gcc 3.2.2 on the one machine I have it installed on. I
> didn't know 3.3 rejected them.

Yes, it has been a long road, but the previous gcc behavior was a 'bug'
even for C89 code that the gcc folks finally fixed.
 
> >To be honest, I wonder why the result of pam_end() is not being captured
> >and causing a call to pam_strerror().
> >
> 
> I'll second that.

Thanks.
 
        Enjoy!
        -- Mark