bugDotGNU Portable.NET - Bugs: bug #10182, pnetC/cscc: incorrect...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #10182: pnetC/cscc: incorrect interpretation of empty prototypes

Submitter:  John Goerzen <jgoerzen>
Submitted:  Fri 27 Aug 2004 07:32:46 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Privacy:  Public
Assigned to:  None Open/Closed:  Closed

Discussion

Thu 16 Sep 2004 12:13:59 AM UTC, comment #1: 

The CLR uses both the name and the signature to identify
a function.  This means that all functions must be properly
prototyped for C code to be successfully compiled to the
CLR.  It isn't possible to guess the parameter types:
is it "unsigned int", "unsigned char", or "int" in
this case?  It could be anything.

I suggest that you fix m4 and submit a patch to its
maintainer.  There are other functions in the m4 code that
are properly prototyped, using _STDC_ to detect ANSI vs
K&R.  They must have missed this one.

Rhys Weatherley <rweather>
Group administrator
Fri 27 Aug 2004 07:32:46 PM UTC, original submission:  

In the GNU program m4 1.4.2 (from ftp.gnu.org/pub/gnu/m4), there is this prototype:

extern void printchar ();

Later on in the code, there's this call:

          printchar (i - 1);

(i is an unsigned int)

We also see:

          printchar (*p++);

p is defined as:

  unsigned char *p = start;

The error cscc raises is:

regex.c:514: too many arguments to function `printchar'

Note that the prototype does not specify void and an empty argument list simply means that the compiler should not check the argument list.

A full build log is attached.

John Goerzen <jgoerzen>

 

Attached Files

Attached Files
file #1687:  buildlog.txt added by jgoerzen (12KiB - text/plain)

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

 

Votes

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.

 

History

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-09-16 rweather StatusNone Wont Fix
    Open/ClosedOpen Closed
2004-08-27 jgoerzen Attached File- Added buildlog.txt, #1616

Back to the top

Powered by Savane 3.16-a7ba.
Corresponding source code