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

 
 

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

Submitted by:  None
Submitted on:  Fri Mar 27 16:19:42 2009  
 
Category: NonePriority: 5 - Normal
Severity: 3 - NormalStatus: Wont Do
Privacy: PublicAssigned to: Bruno Haible <haible>
Originator Email: -unavailable-Open/Closed: Closed
Operating System: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat Dec 3 11:30:04 2016, 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>
Project AdministratorIn charge of this item.
Sat Dec 3 11:11:19 2016, 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>
Project AdministratorIn charge of this item.
Fri Mar 27 16:19:42 2009, 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Dec 3 11:11:19 2016haibleStatusNone=>Wont Do
      Assigned toNone=>haible
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup