Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] Diff of /ckit/trunk/BUGS
ViewVC logotype

Diff of /ckit/trunk/BUGS

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 597, Wed Apr 5 18:34:51 2000 UTC revision 649, Wed May 31 18:04:54 2000 UTC
# Line 31  Line 31 
31  COMMENT: Could not compile example (it is incomplete);  COMMENT: Could not compile example (it is incomplete);
32  Kathleen indicates she can't reproduce this behaviour.  Kathleen indicates she can't reproduce this behaviour.
33    
34    
35    ----------------------------------------------------------------------
36    NUMBER: 14
37    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
38    DATE: 4/17/00
39    TEST:
40    STATUS: open
41    DESCRIPTION: array formals
42    
43    This one is similar to the ?: bug we reported earlier (Bug number 8).
44    
45    void foo(int a[]);
46    
47    int main() {
48      int * ip;
49      foo(ip);
50    }
51    
52    Output:
53    
54    "tt.c":5.3-10: error: Bad function call:
55                   arg 1 has type int * but fn parameter has type int []
56    
57    Correct C output is still produced but the implicit type of ip inside
58    the call to foo has int array type.  This is a problem for our
59    instrumentation.
60    
61    
62    ----------------------------------------------------------------------
63    NUMBER: 15
64    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
65    DATE: 4/17/00
66    TEST:
67    STATUS: open
68    DESCRIPTION: union bitfields
69    
70    According to Harbison and Steele (top of p.141), bitfields in unions are
71    allowed in ISO C, but not "traditional" C.  Neither "gcc -ansi -pedantic",
72    nor cc complains.
73    
74      input:        union { int u16:12; } u;
75    
76      output:       "test.c":1.2-3.4: error: union member has size spec
77    
78                    union t1 { int u16; };
79                    union t1 u;
80    
81    
82    ----------------------------------------------------------------------
83    NUMBER: 16
84    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
85    DATE: 4/17/00
86    TEST:
87    STATUS: open
88    DESCRIPTION: struct bitfields
89    
90    This is not a big deal, since ckit implements a superset of ANSI C,
91    but I thought I'd mention it anyway.  Ckit allows the following:
92    
93    struct S {
94      char a:4;   /* <-- Illegal field for ANSI C, but not "traditional" C */
95      float f:4;  /* <-- Illegal field */
96    };
97    
98    
99    ----------------------------------------------------------------------
100    NUMBER: 17
101    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
102    DATE: 4/14/00
103    TEST:
104    STATUS: open
105    DESCRIPTION: large initializer value
106    
107      Input:
108      ------
109      long i = 0xf8000000;
110      unsigned long i = 0xf8000000ul;
111    
112      Output:
113      -------
114      "test.c":1.11-21: error: large int const
115      "test.c":2.19-31: error: large int const
116      "???": warning: additional errors suppressed.
117      "???": warning: additional warnings suppressed.
118    
119      long i=0;
120      unsigned long i=0;
121    
122      Note:
123      -----
124      gcc -Wall -ansi -pedantic: no complaint
125      cc: warning: initializer does not fit or is out of range: 0xf8000000
126    
127    COMMENT:
128    The problem seems to be due to the fact that LargeInt (i.e. Int32 -
129    signed integer type) is used for storing the value, and LargeInt
130    raises exception Overflow (in c.lex) in the above cases.  IntInf does
131    not overflow on such numbers, and so may be the right thing to use,
132    however that requires changing the code to use IntInf for IntConst.
133    
134    Ironically, LargeInt parses hexadecimal strings fine but IntInf does
135    not handle the 0x prefix for some reason:
136    
137    - let val v = valOf(StringCvt.scanString(LargeInt.scan StringCvt.HEX) "0xff")
138    = in print ((LargeInt.toString v)^"\n") end;
139    255
140    val it = () : unit
141    - let val v = valOf(StringCvt.scanString(IntInf.scan StringCvt.HEX) "0xff")
142    = in print ((IntInf.toString v)^"\n") end;
143    0
144    val it = () : unit
145    - let val v = valOf(StringCvt.scanString(IntInf.scan StringCvt.HEX) "ff")
146    = in print ((IntInf.toString v)^"\n") end;
147    255
148    
149    
150    ----------------------------------------------------------------------
151    NUMBER: 18
152    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
153    DATE: 4/14/00
154    TEST:
155    STATUS: open
156    DESCRIPTION:  old style varargs (INCONVENIENCE)
157    
158    This is something we have an easy workaround for (i.e. using cc -E
159    instead of gcc -E to preprocess) but we mention it in case you think
160    other people might care about this.  When varargs.h is included by
161    gcc -E, old style parameter passing is transformed to this:
162    
163      int foo(a)
164      a;...
165      { }
166    
167      This is not accepted by ckit.
168      Remark: non-ANSI (gcc gives warning)
169      Solution: use cc -E.
170    
171    
172    ----------------------------------------------------------------------
173    NUMBER: 19
174    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
175    DATE: 4/20/00
176    TEST:
177    STATUS: open
178    DESCRIPTION:  incomplete types
179    
180    A change to build-ast.sml since ckit 1.0b3 is annotating types of ids
181    with incomplete types at times.  Our problem is that we use the ast in
182    a separate pass, so we don't see the local symbol tables (unless we
183    redo the work of their construction).  We collect types of declared
184    variables, which we then use in instrumentation.  Incomplete types
185    give us compilation errors.
186    
187    The fixed up type is inserted into the symbol table under line 911,
188    however, the type in the id of the declaration is still the incomplete
189    type.  Subsequent uses of the id will by typed correctly but not the
190    declaration.  The id created on line 916 should be used instead of the
191    original id.
192    
193    Input:
194    
195    int ia[] = {1,2,3};
196    
197    int main() {
198    int ib[] = {1,2,3,4,5};
199    }
200    
201    Types I see in ids for ia and ib in the declarations above are both
202    int[]. :-)
203    
204    
205    ----------------------------------------------------------------------
206    NUMBER: 20
207    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
208    DATE: 5/24/00
209    TEST:
210    STATUS: open
211    DESCRIPTION: long long
212    
213    1. Ckit doesn't really handle long long (it just recognizes the type, but
214       does not handle literals of "long long" size: seems to be due
215       to using LargeInt. See "unsigned long" bug above.
216    
217    2. Should keep around "L", "LL", "UL" suffix to int literals:
218            input:  1LL<<40
219            output: 1<<40   /* compiler complains */
220    
221    3. Tilde and negative:
222            input:  2e-5
223            output: 2E~05
224    
225    Negative numbers are represented with ~ in SML, so that Real.toString
226    called in ppReal prints the ~ in the exponent.
227    
228    
229    ----------------------------------------------------------------------
230    NUMBER: 21
231    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
232    DATE: 5/25/00
233    TEST:
234    STATUS: open
235    DESCRIPTION: spurious error messages
236    
237    Input:
238            struct S {
239              float j;
240              int:24;
241              char * k;
242            } s = {1.2,"3"};
243    
244    Spurious Error Messages:
245            "stst.c":1.2-5.16: error: type of initializer is incompatible with type of lval
246            "stst.c":1.2-5.16: error: badly formed struct initializer: not enough initializers
247    
248    FIX:
249    skip over unnamed members, as per C specs: diff of build-ast.sml (<new,>old) follows:
250    623c623
251    <             let fun f ((fieldType, _, _) :: l, expr :: exprs) =
252    ---
253    >             let fun f ((fieldType, SOME mem, _) :: l, expr :: exprs) =
254    625a626,627
255    >                   | f ((fieldType, NONE, _) :: l, exprs) =
256    >                        f (l, exprs)
257    
258    
259    ----------------------------------------------------------------------
260    NUMBER: 21
261    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
262    DATE: 5/25/00
263    TEST:
264    STATUS: open
265    DESCRIPTION:  const char */char * incompatibility (INCONVENIENCE)
266    
267      input:        char c[100]; const char * d = &c[5];
268                    c - d;
269      output:       error: Type Error: Unacceptable operands of "-" or "--".
270    
271      general:      in general, the error occurs with incompatible pointer types.
272                    the key is to not treat "const" as incompatible.

Legend:
Removed from v.597  
changed lines
  Added in v.649

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0