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/trunk/ckit/BUGS
ViewVC logotype

Diff of /sml/trunk/ckit/BUGS

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

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

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

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