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

SCM Repository

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

Annotation of /ckit/trunk/BUGS

Parent Directory Parent Directory | Revision Log Revision Log


Revision 2092 - (view) (download)

1 : dbm 597 ckit Bug List
2 :     =============
3 :     [Last updated: 3/31/00]
4 :    
5 :     ----------------------------------------------------------------------
6 :     NUMBER: 11
7 :     SUBMITTER: Kathleen Fisher <kfisher@research.att.com>
8 :     DATE: 12/10/99
9 :     TEST:
10 :     STATUS: request for more complete example
11 :     DESCRIPTION:
12 :    
13 :     The code:
14 :     void write_myArray (char *f, char *space, int size)
15 :     {
16 :     Sfio_t *fp;
17 :     int *temp_space = (int *) space;
18 :     int i;
19 :    
20 :     fp = openfile (f,"w");
21 :     for (i = 0; i<2; i++)
22 :     sfprintf (fp,"%d",&(*temp_space)[i]);
23 :     }
24 :    
25 :     passes through the ckit compiler, but cc reports:
26 :    
27 :     "directory008.c", line 866: error(1138): expression must have
28 :     pointer-to-object type
29 :     sfprintf (fp,"%d",&(*temp_space)[i]);
30 :    
31 :     COMMENT: Could not compile example (it is incomplete);
32 :     Kathleen indicates she can't reproduce this behaviour.
33 :    
34 : dbm 649
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 : dbm 654 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 : dbm 649 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 : dbm 650 NUMBER: 22
236 : dbm 649 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.

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