maingperf - Support: sr #106698, Use of C preprocessor to validate...

 
 

sr #106698: Use of C preprocessor to validate character values as ASCII

Submitter:  None
Submitted:  Fri 27 Mar 2009 04:19:42 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Wont Do
Privacy:  Public Assigned to:  haible
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 03 Dec 2016 11:30:04 AM UTC, comment #2: 

Well, there was one more report in
http://lists.gnu.org/archive/html/bug-gperf/2015-09/msg00000.html
but without details.

Bruno Haible <haible>
Group administrator
Sat 03 Dec 2016 11:11:19 AM UTC, comment #1: 

AIX 5.3 is no longer supported, see https://en.wikipedia.org/wiki/IBM_AIX#Versions .

> I checked the 1998 ANSI C++ standard and it states in section 16.1.4 that the numeric values of character literals used during preprocessor expression evaluation do not have to match the values used outside the preprocessor.


But the gperf output heavily relies on the numeric values of character literals. If a compiler vendor chooses to assign different values in the preprocessor and at execution time, we are on too thin ice. Well, gperf could generate an 'enum' instead of a preprocessor expression, like Paul Eggert did in http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=5c592b1c6218391c9869db5051e4ae8561a4935e , but given that 'enum' has different semantics in C++ than in C, this is hairy.

Since this problem has not been reported elsewhere, I assume it's gone.

Bruno Haible <haible>
Group administrator
Fri 27 Mar 2009 04:19:42 PM UTC, original submission:  

I'm using gperf on AIX 5.3 with the IBM xlC compiler.  In version 7 and 8 of xlC the preprocessor does not assign the value of 39 to '\'' and 92 to '\\'.  The version 7 compiler did.  This results in compilation failures because gperf generates a #if stanza that checks each character literal against its ASCII value, and issues a #error if there is a mismatch.

While this is likely a compiler problem, I checked the 1998 ANSI C++ standard and it states in section 16.1.4 that the numeric values of character literals used during preprocessor expression evaluation do not have to match the values used outside the preprocessor.  So I think it think it may be a good idea to add an option to disable this check, or something during configuration that checks for preprocessors with this behavior, or to perhaps do this check some other way.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-12-03 haible StatusNone Wont Do
        Assigned toNone haible
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code