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 654 - (view) (download)
Original Path: sml/trunk/ckit/BUGS

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: 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 : dbm 654 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 : dbm 649 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 : dbm 650 NUMBER: 22
263 : dbm 649 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.

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