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 /sml/releases/release-110.40/ckit/BUGS
ViewVC logotype

Diff of /sml/releases/release-110.40/ckit/BUGS

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

revision 597, Wed Apr 5 18:34:51 2000 UTC revision 654, Thu Jun 8 21:38:04 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: fixed, DBM, 6/8/00
178      Return fixed-up id at the same time as the fixed type (fun processDecr
179      in ast/build-ast.sml)
180    DESCRIPTION:  incomplete types
181    
182    A change to build-ast.sml since ckit 1.0b3 is annotating types of ids
183    with incomplete types at times.  Our problem is that we use the ast in
184    a separate pass, so we don't see the local symbol tables (unless we
185    redo the work of their construction).  We collect types of declared
186    variables, which we then use in instrumentation.  Incomplete types
187    give us compilation errors.
188    
189    The fixed up type is inserted into the symbol table under line 911,
190    however, the type in the id of the declaration is still the incomplete
191    type.  Subsequent uses of the id will by typed correctly but not the
192    declaration.  The id created on line 916 should be used instead of the
193    original id.
194    
195    Input:
196    
197    int ia[] = {1,2,3};
198    
199    int main() {
200    int ib[] = {1,2,3,4,5};
201    }
202    
203    Types I see in ids for ia and ib in the declarations above are both
204    int[]. :-)
205    
206    
207    ----------------------------------------------------------------------
208    NUMBER: 20
209    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
210    DATE: 5/24/00
211    TEST:
212    STATUS: open
213    DESCRIPTION: long long
214    
215    1. Ckit doesn't really handle long long (it just recognizes the type, but
216       does not handle literals of "long long" size: seems to be due
217       to using LargeInt. See "unsigned long" bug above.
218    
219    2. Should keep around "L", "LL", "UL" suffix to int literals:
220            input:  1LL<<40
221            output: 1<<40   /* compiler complains */
222    
223    3. Tilde and negative:
224            input:  2e-5
225            output: 2E~05
226    
227    Negative numbers are represented with ~ in SML, so that Real.toString
228    called in ppReal prints the ~ in the exponent.
229    
230    
231    ----------------------------------------------------------------------
232    NUMBER: 21
233    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
234    DATE: 5/25/00
235    TEST:
236    STATUS: open
237    DESCRIPTION: spurious error messages
238    
239    Input:
240            struct S {
241              float j;
242              int:24;
243              char * k;
244            } s = {1.2,"3"};
245    
246    Spurious Error Messages:
247            "stst.c":1.2-5.16: error: type of initializer is incompatible with type of lval
248            "stst.c":1.2-5.16: error: badly formed struct initializer: not enough initializers
249    
250    FIX:
251    skip over unnamed members, as per C specs: diff of build-ast.sml (<new,>old) follows:
252    623c623
253    <             let fun f ((fieldType, _, _) :: l, expr :: exprs) =
254    ---
255    >             let fun f ((fieldType, SOME mem, _) :: l, expr :: exprs) =
256    625a626,627
257    >                   | f ((fieldType, NONE, _) :: l, exprs) =
258    >                        f (l, exprs)
259    
260    
261    ----------------------------------------------------------------------
262    NUMBER: 22
263    SUBMITTER: Alexey Loginov <alexey@cs.wisc.edu>
264    DATE: 5/25/00
265    TEST:
266    STATUS: open
267    DESCRIPTION:  const char */char * incompatibility (INCONVENIENCE)
268    
269      input:        char c[100]; const char * d = &c[5];
270                    c - d;
271      output:       error: Type Error: Unacceptable operands of "-" or "--".
272    
273      general:      in general, the error occurs with incompatible pointer types.
274                    the key is to not treat "const" as incompatible.

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

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