Skip to content

Commit 29b0b02

Browse files
authored
Merge pull request #82 from trasz/master
Fix punctuation.
2 parents 0513650 + c66dfab commit 29b0b02

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

include/cst_val_const.h

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -48,11 +48,11 @@
4848
/* will use this code as exemplars of why this should be done in C++, I */
4949
/* say good luck to them with their 4M footprint while I go for my */
5050
/* 50K footprint. But I *will* do cst_vals in 8 bytes and I *will* */
51-
/* have them defined const so they are in the text segment */
51+
/* have them defined const so they are in the text segment. */
5252
/* */
5353
/* The problem here is that there is not yet a standard way to do */
5454
/* initialization of unions. There is one in the C99 standard and GCC */
55-
/* already supports it, but other compilers do not so I can't use that */
55+
/* already supports it, but other compilers do not so I can't use that. */
5656
/* */
5757
/* So I need a way to make an object that will have the right 8 bytes */
5858
/* for ints, floats, strings and cons cells that will work on any C */
@@ -82,7 +82,7 @@
8282
/* preprocessor that could convert that. You could make atoms always */
8383
/* have a pointer to another piece of memory, but that would take up */
8484
/* another 4 bytes not just for these constants but all other cst_vals */
85-
/* create */
85+
/* create. */
8686
/* */
8787
/* So you could do */
8888
/* */
@@ -102,7 +102,7 @@
102102
/* At this moment, I think the second version is the least problematic */
103103
/* though it makes defining val_consts more unpleasant than they should */
104104
/* be and forces changes elsewhere in the code even when the compiler */
105-
/* does support initialization of unions */
105+
/* does support initialization of unions. */
106106
/* */
107107
/* */
108108
/*************************************************************************/

0 commit comments

Comments
 (0)